I couldn't find a .stickler.yml file in this repository. I can make one for you, or you can create one by following the documentation.

Comparisons

These work great I think.

Literals

Literals don't work well enough. Should allow for i18n.

I live in Korea. I know individuals that would prefer the literal to look like 2019년 1월 18일 instead of your suggested 2019Y-01M-18D, whereas I wouldn't mind Jan. 18, 2019.

This would mean providing an override inside the checkBox(...) code [is this possible?] or somewhere else in the settings [which is not well established where modifications would go anyways].

You have LocalDate, but what about LocalTime, LocalDateTime, ZonedDateTime, Period, Duration?

@ciscorucinski Thanks for the feedback.

Comparisons actually work for quite a few types, I just didn't list them all explicitly. I probably also forgot a few, but fixing it is as simple as adding a class name to a list.

As for the literals you can also have them displayed as "2019-01-19". I wanted to keep them as close as possible to the actual syntax while keeping legibility. If you switch the order, the entire date will be a folded region. If you keep all the digits in order as they are, you can click into one of the numbers without the template expanding and change it.

Sure, configurable suffixes would be nice but I have no idea how to nicely integrate that into the preferences UI.

@alshain I looked more into where checkBox(...) comes from and it's from BeanConfigurable abstract class. In that class, they provide the concrete framework for dealing with checkboxes, but they also provide support for other JComponents. This is how it would be implemented. But the best UI for this is probably debatable.

I looked at the supported classes, and I saw that only LocalDate was included. That is why I mentioned more support. However,I just saw that inside your new code you have references to other classes. Why are they separate from the supported classes?

As for the ordering issue. I fully agree that keeping the order would look better and won't fold unneeded parts, but dates are very different across all countries. This plugin is meant for the developer to read their own code more easily, and that does mean i18n support should be included where appropriated. There is no more appropriate place than dates.

2015Y-01M-15D seems like a strange date format. Why not go for ISO 8601? E.g. 2015-01-15 or 2015-01-15T12:34:56 or 2015-01-15T12:34:56.789 depending on precision.

@alshain I have merged your PR to my fork